Limitations of Agile Software Processes

Software developers and project managers are struggling to assess the appropriateness of agile processes to their development environments. This paper identifies limitations that apply to many of the published agile processes in terms of the types of projects in which their application may be problematic. INTRODUCTION As more organizations seek to gain competitive advantage through timely deployment of Internet-based services, developers are under increasing pressure to produce new or enhanced implementations quickly [2,8]. Agile software development processes were developed primarily to address this problem, that is, the problem of developing software in "Internet time". Agile approaches utilize technical and managerial processes that continuously adapt and adjust to (1) changes derived from experiences gained during development, (2) changes in software requirements and (3) changes in the development environment. Agile processes are intended to support early and quick production of working code. This is accomplished by structuring the development process into iterations, where an iteration focuses on delivering working code and other artifacts that provide value to the customer and, secondarily, to the project. Agile process proponents and critics often emphasize the code focus of these processes. Proponents often argue that code is the only deliverable that matters, and marginalize the role of analysis and design models and documentation in software creation and evolution. Agile process critics point out that the emphasis on code can lead to corporate memory loss because there is little emphasis on producing good documentation and models to support software creation and evolution of large, complex systems. The claims made by agile process proponents and critics lead to questions about what practices, techniques, and infrastructures are suitable for software development in today’s rapidly changing development environments. In particular, answers to questions related to the suitability of agile processes to particular application domains and development environments are often based on anecdotal accounts of experiences. In this paper we present what we perceive as limitations of agile processes based on our analysis of published works on agile processes [14]. Processes that name themselves “agile” vary greatly in values, practices, and application domains. It is therefore difficult to assess agile processes in general and identify limitations that apply to all agile processes. Our analysis [14] is based on a study of assumptions underlying Extreme Programming (XP) [3,5,6,10], Scrum [12,13], Agile Unified Process [11], Agile Modeling [1] and the principles stated by the Agile Alliance. It is mainly an analytical study, supported by experiences on a few XP projects conducted by the authors. THE AGILE ALLIANCE In recent years a number of processes claiming to be "agile" have been proposed in the literature. To avoid confusion over what it means for a process to be "agile", seventeen agile process methodologists came to an agreement on what "agility" means during a 2001 meeting where they discussed future trends in software development processes. One result of the meeting was the formation of the "Agile Alliance" and the publication of its manifesto (see http://www.agilealliance.org/principles.html). The manifesto of the "Agile Alliance" is a condensed definition of the values and goals of "Agile Software Development". This manifesto is detailed through a number of common principles for agile processes. The principles are listed below. 1. "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." 2. "Business people and developers must work together daily throughout the project." 3. "Welcome changing requirements, even late in development." 4. "Deliver working software frequently." 5. "Working software is the primary measure of progress." 6. "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done." 7. "The best architectures, requirements, and designs emerge from self-organizing teams." 8. "The most efficient and effective method of conveying information to and within a development team is face-toface conversation." 9. "Agile processes promote sustainable development." 10. "Continuous attention to technical excellence and good design enhances agility." 11. "Simplicity is essential." 12. "Project teams evaluate their effectiveness at regular intervals and adjust their behavior accordingly." [TFR02] D. Turk, R. France, B. Rumpe. Limitations of Agile Software Processes. In: Third International Conference on Extreme Programming and Flexible Processes in Software Engineering, XP2002, May 26-30, Alghero, Italy, pg. 43-46, 2002. www.se-rwth.de/publications AN ANALYSIS OF AGILE PROCESSES In this section we discuss the limitations of agile processes that we have identified, based on our analysis of the Agile Alliance principles and assumptions underlying agile processes. The next subsection lists the managerial and technical assumptions we identified in our study [14], and the following subsection discusses the limitations derived from the assumptions. Underlying Assumptions The stated benefits of agile processes over traditional prescriptive processes are predicated on the validity of these assumptions. These assumptions are discussed in more details in another paper [14]. Assumption 1: Customers are co-located with the development team and are readily available when needed by developers. Furthermore, the reliance on face-to-face communication requires that developers be located in close proximity to each other. Assumption 2: Documentation and software models do not play central roles in software development. Assumption 3: Software requirements and the environment in which software is developed evolve as the software is being developed. Assumption 4: Development processes that are dynamically adapted to changing project and product characteristics are more likely to produce high-quality products. Assumption 5: Developers have the experience needed to define and adapt their processes appropriately. In other words, an organization can form teams consisting of bright, highly-experienced problem solvers capable of effectively evolving their processes while they are being executed. Assumption 6: Project visibility can be achieved primarily through delivery of increments and a few metrics. Assumption 7: Rigorous evaluation of software artifacts (products and processes) can be restricted to frequent informal reviews and code testing. Assumption 8: Reusability and generality should not be goals of application-specific software development. Assumption 9: Cost of change does not dramatically increase over time. Assumption 10: Software can be developed in increments. Assumption 11: There is no need to design for change because any change can be effectively handled by refactoring the code [9]. Limitations of Agile Processes The assumptions listed above do not hold for all software development environments in general, nor for all “agile” processes in particular. This should not be surprising; none of the agile processes is a silver bullet (despite the enthusiastic claims of some its proponents). In this part we describe some of the situations in which agile processes may generally not be applicable. It is possible that some agile processes fit these assumptions better, while others may be able to be extended to address the limitations discussed here. Such extensions can involve incorporating principles and practices often associated with more predictive development practices into agile processes. 1. Limited support for distributed development